Integrate the B+-tree with the record manager: Modify your record manager to use the B+-tree for search. That is when creating a new relation with the record manager you should let the user specify which attribute is the key of the table. The record manager should then create and maintain the B+-tree for storing the keys from this attribute. When a new record is inserted, the corresponding key should be inserted in the B+-tree. A scan that searches for a record with a given key should use the B+-tree instead of scanning through all the records. If you want to support keys with more than one attribute, you are allowed to change the b-tree interface to support that.

Allow different data types as keys: Allow the other data types introduced in assignment 3 to be used as keys for the B+-tree.

Implement pointer swizzling: Once a B-tree node is memory, conceptual pointers to that node ( pagenum) should be actual memory pointers. Note that B-trees pages are only pointed to by their intermediate parent node. Thus, a simple way to realize swizzling at page load time, is to immediately replace the pointer to a child node with the memory pointer once some code tries to access it. The complicated part is to make sure that memory pointers are replaced with pagenum if the buffer manager evicts a page from the buffer that was pointed to by a memory pointer. A reasonable way to implement this is to create a bookkeeping data structure that stores all places of pointers to a node that have been replaced by memory pointers. The buffer manager has to be extended with a callback function parameter. This callback is called whenever a page is evicted. For this extension the callback would be a clean-up function that accesses the bookkeeping data structure to figure out where it has to replace memory pointers with page numbers. This data structure is also needed when a node gets evicted that has memory pointer to one or more of its child nodes.

Support multiple entries for one key: Instead of enabling only a single RID to be stored for each key, allow insertions of multiple entries with the same key. You are allowed to change the btree_mgr.h to support accessing all the entries for a key. Please do not change the signature of the findKey method, but rather add a new findAllEntries method that returns an array/list of entries. The findKey should return the first entry only. Instead of RIDs the pointers in leave nodes should reference a page storing all entries for a key. If there are more entries for a key then you can fit onto one page, additional pages should be organized as a linked list. That is each page stores a pointer to the next page.

Your source code directories should be structured as follows. You should reuse your existing storage manager and buffer manager implementations (also record manager if you plan to implement the record manager integration extension). So before you start to develop, please copy these implementations into the assign4 folder.

Put all source files in a folder assign4 in your git repository

This folder should contain at least …

• the provided header and C files

• a make file for building your code Makefile

• a bunch of *.c and *.h files implementing the B+-tree

• README.txt / README.md: A markdown or text file with a brief description of your solution

E.g., the structure may look like that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

   git
      assign4
          Makefile
          buffer_mgr.c
          buffer_mgr.h
          buffer_mgr_stat.c
          buffer_mgr_stat.h
          btree_mgr.c
          btree_mgr.h
          dberror.c
          dberror.h
          dt.h
          expr.c
          expr.h
          record_mgr.c
          record_mgr.h
          rm_serializer.c
          storage_mgr.h
          tables.h
          test_assign4_1.c
          test_expr.c
          test_helper.h